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(54) Method and token for registering users of a public-icey inf rastuture and registration system 



(57) The method allows to register user in a public- 
Icey infrastructure based on credentials, including bio- 
metric data, such as data related to a fingerprint, pre- 
sented to an authority (1 00) of the public-key infrastruc- 
ture, comprising the steps of connecting a token (10), 
comprising a processor (2), an interface device (3) and 
a memory device (5), containing a private-key (51) and 
a public-key (52) for the user of the token (1 0) and a 
private-key (53) issued by the authority (1 00); reading 
biometric data (58) of the user, such as data derived 
from a fingerprint by a biometric input devk^ (1; 31); 
signing the biometric data (58) with the private-key (53) 



issued by the authority (1 00); sending a certifk^ation re- 
quest, containing the public-key (52), signed biometric 
data (58) and additional credentials of the user, to the 
authority (100); verifying and registering the received 
data by the authority (1 00); storing the biometric data 
(58) in a database (1 04); retuming a corresponding cer- 
trfk^te (520) and storing the certificate (520) in the to- 
ken. After registration the token is a secure element of 
the public-key infrastructure allowing to encrypt mes- 
sages and securely sign messages, with digital signa- 
tures, on which a third party can rely on. In case of fraud 
biometric data taken from an unauthorised user can be 
stored in a datat>ase and later legally used as evidence. 
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Description 

[0001] The present invention relates to a method, a 
token and a registration system for registering users of 
a pubtic-lcey infrastructure according to claim 1,12 and 
20 respectively. 

[0002] The present invention relates in particular to a 
method for reliably registering users at an authority of 
the public-key infrastructure in such away that third par- 
ties can trust the issued certifteates. 
[0003] More particularly the present inventk>n relates 
to a method for performing said registration with a token, 
whk:h is capable of processing biometric data. 

BACKGROUND OF THE INVENTION 

[0004] The emergence of the World Wide Web access 
to the Internet has been accompanied by recent focus 
on financial transaction vulnerabilities, crypto system 
weaknesses and privacy issues. Fortunately, techno- 
logk»l developments also made a variety of controls 
available for computer security including tokens, bio- 
metric verifiers, encryption, authentication and digital 
signature techniques using preferably asymmetric pub- 
Irc-key methods (see [1], Richard C. Dorf, THE ELEC- 
TRICAL ENGINEERING HANDBOOK, 2"^ Edition, 
CRC-Press, Boca Raton 1997, chapter 97, pages 
2221-2234 and [7], A. Menezes, P. van Oorschot, S. 
Vanstone, HANDBOOK OF APPLIED CRYPTOGRA- 
PHY, CRC-Press, Boca Raton 1997, chapter 1). 
[0005] The basb security servk^es to be provided are 
secrecy, authentication (assurance of sender identity to 
recipient), and digital signatures (authentication plus as- 
surance to sender and third parties that the signature 
had not been created by the recipient). Also of innpor- 
tance is the notion of integrity which means preventing 
interference in the information conveying^storing proc- 
ess. 

[0006] Almost ail cryptosystems Involve publbly 
known transformations of information, based on one or 
more keys, at least one of which being kept secret. The 
public-key cryptosystem disclosed 1976 by Diffie and 
Hellman is based on two keys, a private-key and a put>- 
lk>-key, owned by users of this system. 
[000^ As described In [2], U.S. Patent document No. 
4,405,829 the public-key cryptosystem provides enci- 
phered communication between arbitrary pairs of peo- 
ple, without the necessity of their agreeing on an enci- 
phering key beforehand. The system of Diffie and Hell- 
man, extended was extended by Tahar El Gamal (see 
[6]) to provide a method for creating a recognizable, un- 
f orgeable, document-dependent, digitised signature for 
a document whose authentrcity the signer cannot later 
deny. 

[0008] The RSA cryptosystem (named after R.L. 
Rivest, A. Shamir and L.M. Adieman which in [2] are 
mentioned as inventors) is the most widely used public- 
key cryptosystem. RSA is a commutative transfomnation 



which allows the private-key and the corresponding 
public-key to be used interchangeably as encryption or 
decryption keys, thus providing secrecy and authentk:ity 
on a secure channel between two parties A and B with 
5 no need for additional keys (see [1 ], pages 2225-2226). 
[0009] Since, given only one key of an asymmetric 
key pair, it is practically infeasible to determine the other 
key, an owner A of a key pair may publish his publk;-key 
so that anyone can use this publb-key to encrypt a mes- 
sage that only A can decipher with his private-key. 
[D010] As described in [3], Marc Branchaud, A SUR- 
VEY OF PUBLIC-KEY INFRASTRUCTURES, Depart- 
ment of Computer Science, Mc Gill University, Montreal 
1997, page 5, computing with public-key ciphers takes 
much longer than encoding the same message with a 
secret-key system. This has led to the practfce of en- 
crypting messages with a secret-key system such as 
DES and then encoding the secret-key with a publk^key 
system such as RSA. In this case the pubric-k^ system 
securely transports the secret-key. In case that a mes- 
sage is sent secretly from A to B then, besides a secret- 
key, which is used optionally, only the key pair of B is 
used. 

p)011] The described public-key system also allows 
owner A to sign a message to be sent to B with a digital 
signature. In this case the key pair of A is used. A en- 
crypts the message or a corresponding hash of the mes- 
sage with his private-key which, on the other side of the 
transmission channel can be decrypted by B using A*s 
public key. One key pair can therefore be used to receive 
an encrypted message orto send a digitally signed mes- 
sage. 

[001 2] B (and any third parties), who can decrypt with 
A's pubric-key a message signed by A, can therefore 
trust that A has signed the message as far as B can trust 
that the selected publk:-key truly belongs to A. 
[QOI 3] In order to ensure that public-keys can system- 
atically be published and truly relate to the persons A, 
B, ... indfeated by attached public-key values, registra- 
tion and cert'rfication authorities (RA, CA) have been in- 
troduced to certify the relationship between a given key 
and a claimed identity. 

[0014] According to [3], page 10, a publk:-key infra- 
structure, in its most simple form, is a system for pub- 
lishing public-key values used in public-key cryptogra- 
phy. There are basic operations, namely registration, 
certification and validation, whk^ are common to all 
public-key infrastructures. 

[0015] Certification is the means by which registered 
public-key values, and information pertaining to those 
values, are published. A baste certif bate therefore con- 
tains at least the public-key of the concerned subject, 
subject identification Infonnation, and identification in- 
fomriation of the certifying authority. 
[001 6] The certificate is encrypted by the certif k^ation 
authority with the certification authority's private-key 
and can be decrypted with the publicly known publte-key 
of the certification authority. In other words a certificate 
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is therefore an encyrypted message issued by the cer- 
tification authority declaring that the therein contained 
public-key relates to the enclosed subject identification 
information. 

[0017] As described in [3], pages 19-21 . authentica- 
tion is a service provided by a public-key infrastructure. 
When a certifying authority certifies an entity and a user 
then validates that certification, the entity is said to have 
been authentk:ated. 

[0018] The degree to which a user can trust the cer- 
tifteate's Infomnation and Ifs vsilidity is a measure of the 
strength of the authentication. 

[0019] [4], U.S. Patent document NO. 6,202,151 B1 
describes a biometric certification system and method 
whk^h implements an end-to-end security mechanism 
binding the biometric identification of the certificate ap- 
plicants with their digital certificate. The binding ts 
achieved by Including biometry measurements in the 
certifteate itself. 

[0020] Prior to use of the disclosed biometric certifi- 
cation system and method, the biometric database Is 
built using a registration process in which individuals are 
required to provide proof of identity. Once the registra- 
tion authority is satisfied with such proof, the identifica- 
tion information is entered into the biometric certification 
management system and biometric measurements are 
then taken concurrently using at least one biometric in- 
put devk». Such stored biometric measurements form 
the pre-stored biometric data in the biometric datak>ase 
whk^h corresponds to the pre-registered individuals who 
have undergone the registration process. 
[0021 ] Accordingly, pre-registered individuals may be 
property authenticated, while unregistered indivkiuals 
are rejected. 

[0022] As mentioned in [4], column 5 the user identi- 
fication data ID may typteally contain 50 bits or less. Bi- 
ometric infonnation, which will be part of the biometric 
certifk:ate, may require a targe amount of memory stor- 
age of up to 4 MB. The end-to-end security mechanism 
described in [4] handles therefore with each transaction 
large amounts of data which for authentication must be 
transferred to a biometric certification management sys- 
tem where the received biometric data are extracted and 
compared with stored biometric data resulting in a high 
workload for each transaction. 

[0023] The process of implementing and handling the 
certification system described in [4] invoh^es therefore 
the use of considerable resources. 
[0024] Users can also be authentrcated through 
something possessed such as a token or a smart card. 
Tokens are, as described in [1], pages 2228-2229, hand- 
carried devices that are normally intended to increase 
password security by assuring that passwords are used 
only once, thereby reducing the vulnerability to pass- 
word compromise. Tokens may contain intematly an al- 
gorithm, which either works in synchronisation with an 
identical algorithm in a host computer or which trans- 
forms an input derived from a computer prompt into a 



password that matches the computer-transfonned re- 
sult. In a pubik:-key infrastructure a token containing a 
private-key may used to sign a message as described 
above. 

5 [0025] The degree of authentk^tion of a user by 
means of a token is however in many cases not strong 
enough. A person, to which the token had been as- 
signed, may, rightfully or not, deny at a later stage that 
the token actually belongs to them or that the token is 

10 no longer in their possession. 

[0026] it would therefore be desirable to improve the 
described pubik:-key infrastructures. It wouki be desir- 
able In particular to improve registration and authenti- 
cation methods in public-key infrastructures thereby in- 

is creasing the reliability of the system while keeping time 
and costs required for registration, authentbation and 
processing at a low level. It would be desirable to pro- 
vide a method allowing to register certificate applicants, 
using a token, at an authority of a public-key infrastruc- 

^ ture in such a way that third parties can trust the certif- 
teate Issued for said certificate applicant. It would also 
be desirable to create a token, which is capable of 
processing biometric data taken from its certifk^te ap- 
plicant. 

25 

SUMMARY OF THE INVENTION 

[0027] The above and other objects of the present in- 
vention are achieved by a method, a token and a regis- 

30 tratk>n system for registering users of a public-key Infra- 
structure according to claim 1,12 and 20 respectively. 
[0028] The inventive method allows users to register 
by means of a token or another secure device at an au- 
thority, preferably the registration authority of a publk:- 

35 key infrastructure based on credentials, Including 
signed biometric data presented to said authority. 
[0029] The biometric data are signed by means of a 
private key issued individually for example by the regis- 
tration authority automaticEdly for each token, making 

40 the token itself part of the registration authority. 

[0030] In addition to signing the biometric data with 
the private key of the registration authority the data can 
further be signed with the user's private key contained 
in the token. 

45 [0031] The token therefore comprises a functionality 
of a registration authority whk;h signifk:antiy increases 
trust Into the inventive system compared to known so- 
lutions. 

[0032] After registration the token is a secure element 
50 of the pubric-key infrastructure allowing the holder/user 
of the token to decrypt encrypted messages sent to 
them and to securely sign messages, with digital signa- 
tures, that can be relied on by a third party. 
[0033] According to the present invention the token 
55 comprises a processor, a memory device, an operating 
system and an Interiace device designed for exchang- 
ing data with a tenninal which Is capable to access the 
network of the public-key infrastmcture. The memory 
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device contains, included in a certificate, a private-key 
and a public-key for the user of the token and a private- 
key issued preferably by the registration authority which 
is used to sign and preferably encrypt biometric data 
read from an internal or external biometric input devce. 
[0034] The token is capable of storing a certifbate 
which has been issued preferably by a certification au* 
thority of the publb-key infrastructure based upon a cer- 
tification request originating from the token. 
[0035] To register a person for issuing a certificate is 
a diff bult process, given the apparently contradk:tory re- 
quirements of, on the one hand, an inexpensh^e and 
convenient registration process and, on the other hand, 
strong mutual identifk:ation and authentk:ation of the 
person and the certification authority, secure mutual ex- 
change of their respective public keys and the secure 
storage of the person's private key on a token. 
[0036] The inventive method allows the generated 
key pair contained in the token to be strongly bound to 
its owner/user since the authority of the publte-key in- 
frastructure, by means of the provkSed private-key is- 
sued by the registration authority, signs the biometric 
data read immediately at the users side. 
[0037] The registration process is therefore consider- 
ably simplified for all parties. 

[0038] Since the binding of the token to the user is 
strong and security of the public-key infrastructure is 
sufficient, even for high level transac^ons, there is no 
need to include the biometric data in the certificate Is- 
sued for the token i.e. the user. Transactions are there- 
fore not burdened with additional data to be transferred 
and processed for authentication purposes. Biometric 
data are therefore not included in each transaction since 
the existence of the biometric data does not increase 
the cryptographk: security of the public key infrastruc- 
ture as whole. 

[0039] The authority of the public-key infrastructure, 
whk:h preferably consists of a registration authority, a 
certification authority and a key and certificate manage- 
ment unit, issues preferably for each token an individual 
key-pair, a private-key used for signing the biometric da- 
ta and a public-key whbh is used for decrypting signed 
messages at the site of the registration authority or, in 
case that it is also stored in the token, as well for en- 
crypting messages, such as the certlftoation request, 
sent to the registratton authority. 
[0040] Instead of or in addition to the public-key of the 
registration authority, the certifk^ate of the certification 
authority or the certification path that validates the cer- 
tification authorit/s certificate may be stored in the to- 
ken so that messages sent to the authority of the public- 
key infrastructure may be encrypted.. 
[0O41 ] I n a prefenred embodiment of the invention the 
biometric Input devbe is integrated in the token which 
facilitates secure and trustworthy registration proce- 
dures and further usage of the token. 
[0042] In order to prevent usage of the token by non- 
authorised persons, additional measures may be taken. 



The memory devtee of the token nnay store a password, 
biometric data or a hash of the biometric data. Access 
to the private- and public-key Is then only granted in 
case that the entered biometric data and/or the pass- 
5 word match the stored values. In the case that the en- 
tered biometric data does not match the stored values, 
then the entered biometric data originating from an un- 
authorised user could also be stored as evidence for le- 
gal prosecution. 
10 [0043] Biometric data in preferred emt>odiments of 
the invention is however protected and never leaves the 
token unencrypted. Only in case of settling a fraud dis- 
pute will biometric data, either stored in the token or in 
the database of the authority, be disclosed for the pur- 
rs poses of expediting legal prosecution. 

[0044] In order to optimise security and to facilitate 
handling of the tokens, the key pair for the user, the pri- 
vate-key and the public-key are preferably generated 
within the token. Critical data, In partteular the data of 
20 the user, and said private keys are preferably not acces- 
sible by external devtees. 

[0045] The invention on the one hand therefore allows 
to strongly authenticate a user I.e. a partner in a trans- 
action and on the other hand protects the user against 
25 misuse of the token without adding noteworthy burden 
onto the usere or operatore of the public-key Infrastruc- 
ture. 

BRIEF DESCRIPTION OF THE DRAWINGS 

30 

[0046] Some of the objects and advantages of the 
present invention have been stated, others will appear 
when the following description is considered together 
with the accompanying drawings, in whk:h: 

35 

Figure 1 shows the schematic of an inventive token 
and 

Rgure 2 shows a public key infrastructure with in- 
40 ventive tokens implemented in a network such as 
the Internet. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

45 

[0047] The inventive token shown in figure 1 is de- 
signed for registering users at an authority 1 00 of a pub- 
lic-key infrastructure whk^h normally comprises a regis- 
tration authority 101 , in charge of registering new users 

50 of the public-key infrastructure, a certification authority 
1 02. in charge of issuing certificates based on approved 
user's certifk:ation requests and a key and certificate 
management unit 1 03, handling and valkJating certifi- 
cates and keys. Issued and revoked certificates of the 

55 users as well as the certificate of the certification author- 
ity 102 are published in a directory 104 to which said 
authorities 101 , 102, 103 and users have access. 
p)048] After the registration has been completed, the 
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token 10 with rfs private key and certificate then builds 
part of the pubtic-key infrastructure, which allows its us- 
er to perform transactions over a network 200 such as 
the Internet. 

[0049] An Inventive token 10, whfeh according to [1], 
pages 2228-2229, is a hand-carried device, comprised 
in its basic embodiment of a processor 2, a memory de- 
vices, an operating system 4 including at least one cryp> 
tographfe engine and an Interface device 3, preferably 
a USB (unh^ersal serial bus) interface, designed for ex- 
changing data with a terminal 20. 30 which is capable 
to access the network servk^ 200 of the public-key in- 
frastructure. The memory device 5 contains a private- 
key 51 and a public-key 52 for a user of the token 10 
and a private-key S3 issued by the authority 100. pref- 
erably by the registration authority 1 01 . 
[0050] In order to optimise security and facilitate han- 
dling the user's key pair, the private-key 51 and the pub- 
Ito-key 52 are preferably generated within the token 10. 
In this case the private-key 51 , before or after the reg- 
istratk>n procedures, win never be available outside the 
token 10. 

[0051] Tokens 10 are therefore normally initialised 
and issued by the authority 1 00. preferably the registra- 
tion authority 101. 

[0052] The token 1 0 comprises an internal biometric 
input device 1 or can be connected via the terminal 30 
to an extemal bk>metric input device 32. Biometric data 
read during the registratk>n procedures by the internal 
or extemal biometric input device 1 . 31 is processed in 
the token 1 0 thereby signing at least said biometric data 
or a dertvate. for example a hash generated thereof, by 
means of the private-key 53 issued by the authority 1 00, 
preferably the registreition authority 101. 
[0053] Signed biometric data, the user's public key 52 
and possibly additional credentials of the user, whksh 
have been transferred through the terminal 20. 30 to the 
token 1 0 are entered into a certification request assem- 
bled preferably based on the Standard PKCS#1 0 (see 
[5], PKCS#10 Standard, Certification Request Syntax 
Standard. RSA Laboratories, May 2000) and sent to the 
authority 1 00, preferably the registration authority 1 01 . 
[0054] The registration authority 101 verifies and reg- 
isters the received data and stores the user's credentials 
Including the btometric data in the database 104. The 
authority 100, preferably the certification authority 102 
then issues based upon the approved certification re- 
quest a certifk:ate 521 containing the user's public key 
52 which then . possibly accompanied by the certification 
authorit/s 102 own certificate, is returned to the token 
10 and stored therein. 

[0055] The at>ove mentioned PKCS#1 0 standard de- 
scribes options for protecting the contents of the certifi- 
cation request. According to the present invention, bio- 
metric data sent as part of a PKCS #10 certificate re- 
quest will be protected for integrity, non-repudiation and 
privacy. 

[0056] In a preferred embodiment of the invention, be- 



sides the private-key 53, the public-key 54 of the regis- 
tration authority 1 01 and^or the public-key 55 of the cer- 
tification authority 1 02 are stored in the memory devk» 
5 of the token 1 0 so that the certifk:ation request or data 
5 contained therein can be encrypted with one of these 
public-key 54, 55 before they are sent to the registration 
authority 101. 

POST] In the case where the encryption of the certifi- 
cation request is perf om^ed with the certification author- 

10 it/s 1 02 publk:-key 55, then the message is decrypted 
by the private-key of the certifteation authority 102. In 
case that the encryption of the certification request is 
perfonned with the registration authority's 101 public- 
key 54, then the message is decrypted by the private- 

is key 53 of the registration authority 1 01 . 

[0058] In order to optimise security the authority 1 00, 
preferably the registration authority 1 01 , issues for each 
token 10 an individual key-pair, a public-key 54 and a 
private-key 53, which is used for signing the biometric 

20 data. 

[0059] In order to facilitate the retrieval of the required 
keys 53, 54 at the registration authority 101 the certifi- 
cation request is preferably accompanied by a serial 
number 56, which Is stored In the memory device 5 of 

25 the token 1 0. The key pair 53. 54 issued for a token 1 0 
is therefore preferably linked to its serial number, 
ipoeo] Since none of the keys for signing the biometrk; 
data 58 are publicly avail^le. the authority 100. prefer- 
ably the registration authority 1 01 , may use an asym- 

30 metric key pair 53, 54 or a symmetric key pair for signing 
the biometric data 58. In case that a symmetric key is 
enclosed in the token 1 0, then the registration authority 
1 01 my find the corresponding symmetric key by means 
of the serial number of the token 1 0. In the same manner 

3S instead of a symmetric key a shared password, a pass- 
word contained in the token 10 and a corresponding 
password stored at the registration authority 1 01 , could 
be used for signing the biometrk; data 58. However as 
described above the use of an asymn^etrical key pair is 

40 preferred compared to the use of a symmetrical key or 
a shared password, since sharing symmetrical keys or 
passwords always involves additional risks. 
[0061] After the registration process has been com- 
pleted and a certifk:ate 521 has been issued the token 

45 is strongly linked to its user, so that based on the pro- 
vided reliability and trust, high level transactions can be 
executed, since the user of the token can reliably be au- 
thenticated. 

[0082] In order to protect the user against losses in 
^ case of theft of the token, biometric data 58 or a deriv- 
ative such as a hash thereof or a password is preferably 
stored in the memory device 5. The password and fur- 
ther credentials of the user are stored In block 57 of the 
memory device 5 shown in figure 1 . Access to the func- 
55 tions of the token 1 0 is then provided only when a pass- 
word entered and/or biometric data read by the Internal 
or extemal biometric Input device 1, 31 matches the 
stored values. 
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[0063] The comparison of said data is preferably done 
within the token 10. The system is therefore not bur- 
dened with access procedures during which relatively 
large amounts of data need to be transferred. 
[0064] It is however possible that biometric data read 
from the current user of the token 1 0 are transferred to 
the authority 100 for verifk»tion purposes, in the case 
that delivered values do not match stored values, data 
access is denied. The biometric data could optionally be 
stored in the database 1 04 or in the token (when used 
ofnine),for legal prosecution of non-authorised users of 
the token 10. 

[0065] Figure 2 shows a public key infrastructure with 
inventive tokens 1 0a, 1 0b, 1 0c implemented in a net- 
v/ork 200 such as the Intemet. The authority 1 00 shown 
consists of a registration authority 101, a certification 
authority, a key and certiTicate management unit 103 
and a database 1 04 containing the directory of the public 
key Infrastructure. The users of tokens 10a and 10b, 
which contain integrated biometric data input devtees 1 
are connected to temninals 20 through whk^h transac- 
tions can be carried out with users other tenminals 20, 
40. 

[0066] Figure 2 f u rther shows a registration system 35 
whk^h is preferably installed in places where tokens 10 
can be obtained. In particular registration procedures 
with tokens 10 which do not contain an Integrated bio- 
metric data input device 1 are perfomned with a regis- 
tration system 35 which comprises a terminal 30 and a 
at least one device 31 capable of reading biometrk: data 
of a user. The registration system 35 may be connected 
to a scanner for reading fingerprints, to a camera or to 
a voice recorder. 

[0067] Although the present invention has been de- 
scribed in detail with reference to preferred embodi- 
ments, persons having ordinary skill in the art will ap- 
preciate that various modlTications and different imple- 
mentations may be made without departing from the 
spirit and scope of the invention. 
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15 Claims 

1. Method for registering users of a public-key infra- 
structure based on credentials of a user, including 
biometric data such as data related to a fingerprint, 
20 presented to an authority (1 00) of the pubfic-k^ in- 
frastructure, comprising the steps of 

a) connecting a token (10), 

which comprises a processor (2), an in- 
2S terface device (3) and a memory device (5), 

containing a private-key (51) and a publb-key 
(52) for the user of the token (1 0) and a private- 
key (53) issued by the authority (100); 

to a terminal (20, 30) capable to access 
30 the network (200) of the public-key infrastruc- 

ture, 

b1 ) reading biometric data (58) of the user, such 
as data derived from a finger print of the user, 
35 by a bk>metric input device (1 ; 31 ); 

b2) signing the biometric data (58) with a key 
of an asymmetric or symmetrk; key pair or by 
means of a shared password issued by the au- 
40 thority (100); 

b3) sending a certification request, containing 
the publk:-key (52), signed biometric data (58) 
and additional credentials of the user, to the au- 
45 thority (100); 

c1) verifying and registering the recehfed data 
by the authority (1 00); 
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55 



c2) storing the biometric data (58) in a database 
(104); 

c3) returning a corresponding certlfteate (520) 
and 

d) storing the certifteate (520) in the token. 
2. Method according to daim 1 comprising the steps 
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of double signing the biometric data witti said key 
of an asymmetiic or symmetric key pair or by means 
of a shared password and the user's private key 
(51). 

3. Method according to claim 1 or 2» with a serial 
number of the token being stored in the memory de- 
vice (5), which, included in the certification request, 
is sent to the authority (1 00) whk:h, based on said 
serial number, retrieves the symmetric or asymmet- 
ric key or the password matching the Icey or pass- 
word used for signing the biometric data (58) in or- 
der to decrypt the signed message. 

4. Method according to claim 1 , 2 or 3 for a public-key 
infrastructure with an authority (1 00), consisting of 
a registration authority (1 01), a certification author- 
ity (1 02) and a key and certifk^ate management unit 
(103), comprising the steps of issuing for each to- 
ken (10) an indhridual symmetric or asymmetric 
key-pair, a first key stored in the token (1 0) for sign- 
ing the biometric data (58) and a second key (54) 
stored at the registration authority (101). 

5. Method according to claim 1 , 2, 3 or 4 with the pub- 
lic-key (54; 55) of the registration authority (101) 
and or the certification authority (102) being stored 
in the token (1 0), comprising the steps of encrypting 
at least the part of the certifteation request contain- 
ing the biometric data with one of said public-keys 
(54; 55) before sending It and decrypting the re- 
ceived certifbation request by the registration au- 
thority (101) with the con-esponding private-key 
(53, ...). 

6. Method according to one of the claims 1 -5 with the 
biometric Input device (31) being integrated in the 
token (10) comprising the step>s of pressing a finger 
onto the token (1 0) while biometric data (58) is read. 

7. Method according to one of the claims 1 -6 compris- 
ing the steps of storing the biometric data (58) or a 
hash of the biometric data (58) in the memory de- 
vice (5) and/or storing a password in the memory 
device (5). 

8. Method according to one of the claims 1 to 7 com- 
prising the steps of comparing a password entered 
with the password stored in the token (1 0) and/or 
reading biometrk: data from the user and comparing 
biometric data read with biometric data (58) stored 
in the token (1 0) or in the database (1 04) of the au- 
thority (100) and providing access to the system In 
case that the compared data match and/or storing 
mismatched data as proof for legal prosecution of 
a non-authorised user of the token 10. 

9. Method according to one of the dainns 1 to 8 com- 



prising the steps of generating the key pair for the 
user, the private-key (51) and the publb-key (52) 
within the token (1 0). 

5 10. Method according to one of the claims 1 to 9 com- 
prising the steps of performing transactions defined 
by the authority of the public-key infrastructure 
while using the registered token (10). 

10 11. Method according to one of the claims 1 to 1 0 com- 
prising the steps of keeping the user's data, partte- 
ulariy the biometrk; data, private except for cases 
of fraud. 

12. Token (1 0) designed for registering users at an au- 
thority (100) of a publte-key infrastructure pgirticu- 
lariy according to the method of claim 1 , connprising 
a processor (2), a memory devk^ (5), an operating 
system (4) and an interface devk» (3) designed for 

20 exchanging data with a terminal (20, 30) whbh is 
capable to access the network (200) of the publk:- 
key infrastructure, characterised in that 

a) the memory device (5) contains a private-key 
25 (51) and a public-key (52) for a user of the token 

(1 0) and a private-key (53) issued tyy the au- 
thority (100); 

b) the token (1 0) is capable of processing bio- 
30 metric data (58) read and transfeaed from an 

internal or extemal biometric input device (31); 

c) the token (1 0) is capable of signing the read 
biometric data (58) with a key of an asynrvnetric 

35 or symmetric key pair or by means of a shared 

password issued by the authority (1 00); 

d) the token (10) is capable of storing a certifi- 
cate (520) which has been issued by the au- 

40 thority (1 00) based upon a certification request 

originating from the token (1 0). 

1 3. Token (1 0) according to claim 1 2 capable of signing 
the read biometric data (58) with the key of the 

^ asynrvnetrte or symmetric key pai r or by means of a 
shared password and the user's private key (51). 

1 4. Token (1 0) according to claim 1 2 or 1 3, with a serial 
number of the token being stored in the memory de- 

50 vfce (5). 

1 5. Token (1 0) according to claim 1 2, 13 or 1 4 for a pub- 
lic-key infrastructure with an authority (1 00), con- 
sisting of a registration authority (101), a certifica- 

55 tion authority (102) and a key and certificate man- 
agement unit (103), comprising an individual key of 
a symmetric or asymmetric key-pair or a shared 
password for signing the biometric data (58) and a 
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publiC'key (55) issued by the registration authority 
(1 01 ) or the certification authority (1 02) for encrypt- 
ing the certification request sent to the authority 
(100). 

5 

16- Totcen (10) according to one of theclainns 12-15 with 
the biometric input device (1) being integrated In the 
token (10). 

17. Token (1 0) according to one of the claims 1 2-1 6 de- io 
signed to store the read biometric data (58) or a 
hash of the biometric data (58) in the memory de- 
vice (5) and/or storing a password in the memory 
device (5). 

IS 

1 8. Token (1 0) according to one of the claims 1 2-1 7 ca- 
pable to compare a password entered with the 
password stored in the token (10) and/or capable 
of reading biometric data from the user and com- 
paring biometric data read with biometric data (58) 20 
stored in the token (1 0) providing access to the sys- 
tem in case that the compared data match. 

19. Token (1 0) according to one of the claims 1 2-1 8 ca- 
pable to gen eratin g the key pair for the user, the pri- 2S 
vate-key (51) and the publk;-key (52), within the to- 
ken (10). 

20. Registration system (35) providing access to a to- 
ken (1 0) according to one of the dalnns 1 2-1 9 with 30 
a terminal(30) designed to exchange data with the 
network (200) of the public-key infreistructure, with 

a connected token (10) and with at least one bio- 
metric input device (31) capable of reading biomet- 
ric data, preferably as data related to a fingerprint, 3s 
the retina, the face and/6 r the voice of a user which 
bionnetric data is transferable via the tenmlnai (30) 
to the token (1 0) for processing. 



8 



EP 1 263 164 A1 




9 



EP1 263 164A1 




10 



EP1 2e3164A1 




Office 



EUROPEAN SEARCH REPORT 



EP 01 81 0637 



EKX^UMENTS CONSIDERED TO BE RELEVAfTT 



Category 



Cttadon of dCMSumont wUi i n d i ca B ow, wAioro appropriate, 
of retovarrt passatpw 



todakn 



APPUCAHOM (liitCL7> 



wo 98 50875 A (GTE GOVERNMENT SYST ;GTE 
SERVICE CORP (US)) 

12 November 1998 (1998-11-12) 

* page 7, line 4 - line 19 * 

* page 8, line 6 - line 16 * 

* page 9, line 9 - line 27 * 

* claim 16 * 

* figure 3 ♦ 

EP 0 999 528 A (ELSDALE LIMITED) 
10 May 2000 (2000-05-10) 
"0 column 2, line 6 * 

* column 4, line 22 - column 5, line 23 * 

* column 8, line 39 * 

* paragraphs 

*0006! , '00221 /0023! , '0039! , '0041! « 

R. FOURNIER, T. KAMIONEK: "The 
Cryptographic Smart Card: An Integrated 
Solution' 

RSASECURITY WEB SEHINARE, 'Online! 

25 April 2001 (2001-04-25), pages 1-30, 

XP002213544 

Retrieved from the Internet: 
<URL:wwM.rsasecurity.con> 
'retrieved on 2002-09-05! 

* page 4 - page 8 * 

* page 13 - page 23 4^ 

* page 13 - page 23 * 

US 6 189 096 81 (HAVERTY RAND) 

13 February 2001 (2001-02-13) 

4* coliom 3, line 42 - column 4, line 5 ♦ 

* column 9» line 42 - column 10, line 34 * 

* column 15, line 46 - line 60 * 

* figure 10 * 

-/— 



1-20 



H04L9/32 



1-20 



1-20 



OntJCLT} 



G07C 
H04L 
H04K 
B60R 
Ga7F 
G06F 



1-20 



Ttio present search report has been ciraimi up for all claims 



MUNICH 



25 September 2002 



Bee, T 



CATEGORY OF CITED DOCUMENTS 

X : partfoulariy relevant If taMen alone 
Y : potailariy relsmt If combined with another 

document of the same calei 

A : lecnnoto(^cal badq^cund 
O : non-wnttan disclosure 
P : Intennediabe dcxaiment 



T : Vieofy or principle underlying the InvenSon 
E :earfler patent document, but published o% or 

Bfter Iho lUtoQ dale 
D : document dtad fan the ^::pilcatton 
L : document dtod for other reaso-rs 



& : member of ttie same patent temly, corresponding 



11 



EP1 263164A1 



European PMtenI 



EUROPEAN SEARCH REPORT 



EP 01 81 0637 



DOCUMENTS CONSIDERED TO BE RELEVANT 



CatagcMy 



CitaSton of doc um gnt with indication, 
of nrttvant passapas 



Relevant 
tociaim 



MPPUGMHOH QntOJ) 



US 5 280 527 A (FAST NORMAN ET AL) 
18 January 1994 (1994-01-18) 

* column 3, line 37 - column 4, line 9 * 

* column 4, line 37 - line 64 * 

* column 5, line 33 - column 6, line 5 * 

* figures 1-3 * 

POLEMI D: "TTPs and biometrics for 
securing the payment of telemedical 
services" 

FUTURE GENERATIONS COMPUTER SYSTEMS » 
ELSEVIER SCIENCE PUBLISHERS. AMSTERDAM, 
NL, 

vol. 15, no. 2, 

11 March 1999 (1999-03-11), pages 265-276. 

XP004222994 

ISSN: 0167-739X 

* paragraph '00051 * 



1-20 



12-19 



TGCHMCAL RELOS 
SEARCHED (In^CLT) 



The present search report has been drsMvn up for all claims 



PlmarMarah 


Oato or coniplittenor the aawoh 




MUNICH 


25 September 2002 


Bec» T 



CATEGORY OF CITED DOCUMENTTS 

X : pamcularly relevant V iafcan aione 

Y : parDoiarfy relevant V combined wHh another 

documental the samo cateoory 
A : tschnolog^caJ backgrDund 
O : non willkN i dlsdosue 
P • InternwdtalB doouTient 



TiiiBOryo^ principle undarlyino 
E : oyfar patorrt document but pufclshed on, or 

afler ttie filing data 
O : document oltad In the appflcatlon 
L ! document dtcd for other reasons 

mamber of the same psderttfaml^. oonespondlng 



12 



EP1 263164A1 



ANNEX TO THE EUROPEAN SEARCH REPORT 
ON EUROPEAN PATENT APPUCATION NO. 



EP 01 81 0637 



This armaoc lists the palant tamOy membens relating to the patent documents citad bi the above-menlioned Eurapoan search report. 
The meifibeiB are as contained in the European Patant Office EDP file on 

The Biropeon Paianl Office is In no way liable for these particulars wMch are nnarelyghren for the purpose of information. 

25-09-2002 



Patent document 

bia 



PublicBtion 



Is) 



HO 9850875 



12-11-1998 



AU 
BR 
CN 

EP 
JP 
US 
US 
US 
US 
UO 



7484898 A 
9808737 A 
1274448 T 
0980559 A2 
2002501700 T 
6105010 A 
6202151 Bl 
6208746 Bl 
6310966 Bl 
9850875 A2 



EP 0999528 



10-05-2000 



DE 
EP 



19851074 Al 
0999528 A2 



US 6189096 



Bl 



13-02-2001 



AU 3624599 A 

CA 2330958 Al 

CN 1299545 T 

EP 1076953 Al 

UO 9957846 Al 

JP 2002514842 T 



US 5280527 



18-01-1994 CA 



2105404 Al 



8) Fdr more details atiouttibarmex: see Offidal Journal of the European PederrtOffbe. Kb. 12/82 



27-11- 
16-01- 

22- 11- 

23- 02- 
15-01- 
15-08- 
13-03- 
27-03- 
30-10- 
12-11- 



1998 
'2001 
2000 
2000 
-2002 
2000 
2001 
•2001 
2001 
1998 



11-05-2000 
10-05-2000 



23-11-1999 
11-11-1999 
13-06-2001 
21-02-2001 
11-11-1999 
21-05-2002 



03-03-1995 



13 



